Transport Layer Security (TLS) is the standard protocol for providing authenticity and confidentiality on top of TCP connections. Today, it is used to provide a secure version of traditional protocols (e.g., IMAP, SMTP, XMPP, etc.); in particular, the usage of HTTP over TLS is commonly known as HTTPS. Each TLS connection begins with a handshake between a server and a client. In this handshake, the Public Key Infrastructure (PKI) suite is used to authenticate the server (and eventually the client) and to generate cryptographic keys to create a secure channel over which data are transmitted.
TLS has seen wide adoption and is currently carrying a significant fraction of the overall HTTP traffic (Facebook™, Google™ and Twitter™ use it by default). TLS makes the fundamental assumption that all functionality resides solely at the endpoints, and is thus unable to utilize the many in-network services that optimize network resource usage, improve user experience, and protect clients and servers from security threats. Reintroducing such in-network functionality into secure TLS sessions today is done through hacks, in many cases weakening overall security.
Four solutions aiming to insert middleboxes in TLS sessions are at present known:                Custom root certificate: This solution consists of installing a custom root certificate on a client, allowing the middlebox to create a certificate for itself purporting to be the intended server. The middlebox then connects to the server and passes the data from one connection to the other. Contrary to present invention, in this solution, there is no mechanism for authenticating the middlebox. Even worse, the middlebox is completely transparent to the server. On the client, only a deep inspection of the certificate chain would reveal the presence of a forged certificate. Moreover, the client has no guarantees beyond the first hop. While the connection to the middlebox is encrypted, the client cannot verify that TLS is being used from the middlebox to the server, whether additional middleboxes are present, or whether the endpoint of the session is even the intended server. Also, middleboxes get full read/write access to the data stream. In one hand, many middleboxes only need selective access to the data stream. In the other hand, clients should be empowered with control on what data to share or not. Finally, endpoints (and middleboxes) cannot detect in-flight modifications.        “I'm a proxy” certificate flag: A 2014 IETF draft from Ericsson™ and AT&T™ that proposes using the X.509 Extended Key Usage extension to indicate that the certificate belongs to a proxy [1]. Upon receiving such a certificate during a TLS handshake protocol, the client agent would omit the domain name check (presumably after securing user permission) and establish a TLS session with the proxy, which would in turn open a connection with the server. Based on client preferences, the client agent might only accept proxy certificates for certain sessions. In this case, the client has no guarantees beyond the first hop, and middleboxes get full read/write access to the data stream. Moreover, in this solution, endpoints (and middleboxes) cannot either detect in-flight modifications.        Pass Session Key Out-of-Band: Another IETF draft, this one from Google™ assumes that the client maintains a persistent TLS connection with the proxy and multiplexes multiple sessions over that connection. After establishing an end-to-end TLS connection with the server (which the proxy blindly forwards), the client passes the session key to the proxy before transmitting data on the new connection [2]. Again, the user agent can selectively grant the proxy access on a per-connection basis based on user preference. This solution suffers in that middleboxes get also full read/write access to a TLS session. Compared to the solutions above, this approach limits a middlebox access to the TLS session specifically indicated by the client. However, within a TLS session a middlebox still gets full read/write access. Moreover, the server is unaware that trusted middleboxes are added to a secure session at the consent of both endpoints, and endpoints (and middleboxes) cannot either detect in-flight modifications.        Ship a Custom Browser: This solution consists of modifying the browser itself to accept certificates from certain trusted proxies. This is the approach Viasat™ is taking for its Exede® satellite Internet customers. In this solution, there is neither a mechanism for authenticating the middlebox, being the middlebox transparent to the server. On the client, only a deep inspection of the certificate chain would reveal the presence of a forged certificate. Moreover, the client has neither guarantee beyond the first hop. While the connection to the middlebox is encrypted, the client cannot verify that TLS is being used from the middlebox to the server, whether additional middleboxes are present, or whether the endpoint of the session is even the intended server. Middleboxes get also full read/write access to the data stream. In one hand, many middleboxes only need selective access to the data stream. In the other hand, clients should be empowered with control on what data to share or not. Also, this solution requires custom browser installation, and endpoints (and middleboxes) cannot either detect in-flight modifications.        